REMARKS 

Reconsideration and allowance of the above-referenced application are respectfully requested. 
Claims 1-64 are pending in the application. 

Claims 1-6, 13-23, 27-37, 44-54, and 58-64 were rejected under 35 USC §102(e) in view of 
U.S. Patent No. 6,549,612 to Gifford et al. This rejection is respectfully traversed. 

Each of the independent claims specifies converting between the media type of the message 
associated with the prescribed messaging operation and the corresponding e-mail message having the URL 
encoded string and the MIME type specified in the header of the e-mail. 

Hence, the claimed application server is able to store any type of message within the message store, 
regardless of the corresponding media type, based on converting the message into a generic format 
message that is represented as a URL encoded string, and specifying the original MIME type within an e- 
mail header, and then attaching the URL encoded string and the header specifying the MIME type within 
the e-mail for storage in the messaging server. 

The Examiner contends that Gifford et al. teaches converting between the media type of the 
message associated with the prescribed messaging operation and the corresponding e-mail message having 
the URL encoded string and the MIME type specified in the header of the e-mail. In support, the 
Examiner cites columns 6-8 of Gifford et al. and states, "Gifford discloses that manipulation of URL 
encoded strings control formatting and transmission of stored messages." This is not a teaching of the 
converting step as claimed. As described at column 7, lines 55-59 of Gifford et al., the URL links merely 
reference a CGI program that returns a dynamically constructed image which contains current information. 
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In other words, the claimed URL encoded string represents the message (i .e., contains actual data), 
as opposed to the conventional use of URLs to merely reference (i.e., locate) a resource (see Exhibit A, 
pages 1 -2 of RFC 1 738 which defines Uniform Resource Locator). There is no teaching or suggestion 
in Gifford to use a URL encoded sting to represent the message as claimed. 

Hence, the rejection should be withdrawn because it fails to demonstrate that Gifford et al. disclose 
each and every element of the claim . See MPEP 2131. "The identical invention must be shown in as 
complete detail as is contained in the ... claim." Richardson v. Suzuki MotorCo. , 868 F.2d 1226, 1236, 
9 USPQ2d 1913,1 920 (Fed. Cir. 1 989). "Anticipation cannot be predicated on teachings in the reference 
which are vague or based on conjecture." Studiengesellschaft Kohle mbH v. Dart Industries. Inc. . 549 F. 
Supp. 716, 216 USPQ 381 (D. Del. 1982), afFd. . 726 F.2d 724, 220 USPQ 841 (Fed. Cir. 1984). 

The rejections under §103 of claims 7-8, 9-12, 24-26, 40-43, 55-57 are moot in view of the 
foregoing. 

In view of the above, it is believed this application is and condition for allowance, and such aNotice 
is respectfully solicited. 
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To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 1 . 1 36. 
Please charge any shortage in fees due in connection with the filing of this paper, including any missing or 
insufficient fees under 37 C.F.R. 1 . 1 7(a), to Deposit Account No. 50-1 1 30, under Order No. 95-41 5, 
and please credit any excess fees to such deposit account. 



Respectfully submitted, 
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Status of this Memo 



This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 



Abstract 



This document specifies a Uniform Resource Locator (URL) , the syntax 
and semantics of formalized information for location and access of 
resources via the Internet . 



1. Introduction 

This document describes the syntax and semantics for a compact string 
4 representation for a resource available via the Internet. These 
strings are called "Uniform Resource Locators" (URLs) . 

The specification is derived from concepts introduced by the World- 
Wide Web global information initiative, whose use of such objects 
dates from 1990 and is described in "Universal Resource Identifiers 
in WWW" , RFC 1630. The specification of URLs is designed to meet the 
requirements laid out in "Functional Requirements for Internet 
Resource Locators" [12] . 



This document was written by the URI working group of the Internet 
Engineering Task Force. Comments may be addressed to the editors, or 
to the URI-WG <uri@bunyip. com> . Discussions of the group are archived 
at <URL:http: //www.acl . lanl .gov/URI/archive/uri -archive . index. html> 



Berners-Lee, Masinter & McCahill 



[Page 1] 



RFC 1738 



Uniform Resource Locators (URL) 



December 1994 



2 . General URL Syntax 

Just as there are many different methods of access to resources, 
there are several schemes for describing the location of such 
resources . 

The generic syntax for URLs provides a framework for new schemes to 
be established using protocols other than those defined in this 
document . 

URLs are used to " locate ' resources , by providing an abstract 
identification of the resource location. Having located a resource, 
a system may perform a variety of operations on the resource, as 
< might be characterized by such words as "access*, "update 1 , 

"replace', "find attributes'. In general, only the "access' method 
needs to be specified for any URL scheme. 

2.1. The main parts of URLs 

A full BNF description of the URL syntax is given in Section 5. 

In general, URLs are written as follows: 

<scheme> : <scheme-specif ic-part>* 

A URL contains the name of the scheme being used (<scheme>) followed 
by a colon and then a string (the <scheme-specif ic-part>) whose 
interpretation depends on the scheme. 

Scheme names consist of a sequence of characters. The lower case 
letters "a" - - "z " , digits, and the characters plus (" + "), period 
("."), and hyphen ("-") are allowed. For resiliency, programs 
interpreting URLs should treat upper case letters as equivalent to 
lower case in scheme names (e.g., allow "HTTP" as well as "http") . 

2.2. URL Character Encoding Issues 

URLs are sequences of characters, i.e., letters, digits, and special 
characters. A URLs may be represented in a variety of ways: e.g., ink 
on paper, or a sequence of octets in a coded character set. The 
interpretation of a URL depends only on the identity of the 
characters used. 

In most URL schemes, the sequences of characters in different parts 
of a URL are used to represent sequences of octets used in Internet 
protocols. For example, in the ftp scheme, the host name, directory 
name and file names are such sequences of octets, represented by 
parts of the URL. Within those parts, an octet may be represented by 
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